View figure.
In this chapter, you will find the following examples which demonstrate basic VPN solutions:
This example uses IPSec with automatic key generation and pre-shared keys. In Figure 20-1, a secure tunnel is created from gateway to gateway. This tunnel will authenticate and encrypt traffic from specific hosts and will exclude all other traffic. The profile describes exactly which hosts at either end of the tunnel are allowed to pass data through the tunnel. The policy can allow a single host on either end, single or multiple subnets on either end, or any combination of the two. The limitation of gateway to gateway tunneling is that no authentication or encryption occurs on the LAN. This solution does not provide security on the LAN.
The network used for this example (Figure 20-1) consists of two token-ring segments connected by two IBM 2210 routers. In a real scenario, the serial link between the routers could be any private or public wide-area network (WAN).
Figure 20-1. Physical Network Used for Example Configurations
| View figure. |
In Figure 20-2, the tunnel must authenticate and encrypt all traffic between Subnet 9.24.106.0 (via branch router VPNRTR2 and corporate router VPNRTR1) and Subnet 192.168.141.32. No other traffic from any other subnet may traverse the link between the two routers. Authentication guarantees that a tunnel is set up between the correct endpoints, and encryption protects the data from being interpreted as it crosses the WAN.
Figure 20-2. Sample Network Used for IPSec With Pre-Shared Keys
 View figure. |
Follow these steps to configure the router:
From the Talk 6 command line interface, enable IP Security at the box level.
Table 20-1. Enable IP Security
VPNRTR1 *TALK 6 Gateway user configuration VPNRTR1 Config>feature ipsec IP Security feature user configuration IPsec config>ipv4 VPNRTR1 IPV4-IPsec config>ENABLE IPSEC It is necessary to restart the router for IPsec to be active. VPNRTR1 IPV4-IPsec config>EXIT VPNRTR1 IPsec config>EXIT |
A pre-shared key must be configured for every remote user. Because of this, pre-shared keys are not very scalable. However, pre-shared keys are refreshed on a regular basis, giving them an advantage over the manual tunnel method.
The Talk 6 Add User command is used to configure the keys.
VPNRTR1 Config>FEATURE Policy
IP Network Policy configuration VPNRTR1 Policy config>ADD USER
Choose from the following ways to identify a user: 1
1: IP Address
2: Fully Qualified Domain Name
3: User Fully Qualified Domain Name
4: Key ID (Any string)
Enter your choice(1-4) [1]? 1
Enter the IP Address that distinguishes this user
[0.0.0.0]? 192.168.141.17 2
Group to include this user in []?
Authenticate user with 1:pre-shared key or 2: Public Certificate [1]? 1
Mode to enter key (1=ASCII, 2=HEX) [1]? 1
Enter the Pre-Shared Key (an even number of 2-128 ascii chars):
Enter the Pre-Shared Key again (3 characters) in ascii: 3
Here is the User Information you specified...
Name = 192.168.141.17
Type = IPV4 Addr
Group =
Auth Mode =Pre-Shared Key
Key(Ascii)=key 3
Is this correct? [Yes]:
|
A policy is the framework for describing how traffic entering or leaving the router is to be handled. Without access control, the router only makes routing decisions. Using the policy, the router makes decisions such as whether to pass the packet across the interface, whether the packet needs to be authenticated and whether the packet needs to be encrypted or decrypted. The policy ties other objects together. This example uses the Add Policy command first. This is probably the easiest way to create the first policy, since it prompts you to enter all the necessary information in the correct order.
If a policy creates a security tunnel, only the packets matching the profile will be encrypted and forwarded. Other packets not matching the profile are passed in the clear unless explicitly dropped by another policy. When more than one policy exists on a router, the policies are evaluated according to priority number.
Refer to Figure 20-3 to see how an incoming packet is evaluated against multiple policies. If the packet matches the profile for Policy #1, it is sent to IPSec for processing. If the packet does not match the profile for Policy #1, it is evaluated against the profile for Policy #2. This process continues until the incoming packet is evaluated against all policies. If the packet did not match any profile, it would be sent in clear text to the routing protocol for processing.
Figure 20-3. Effect of Multiple Policies
 View figure. |
Table 20-3. Create a New Policy
VPNRTR1 Policy config>ADD POLICY
Enter a Name (1-29 characters) for this Policy []? ike-pre-32-106
Enter the priority of this policy (This number is used to determine
the policy to enforce in the event of policy conflicts) [5]? 15 1
List of Profiles:
0: New Profile 2
|
The profile describes the criteria used to determine if a packet should be acted on by the policy. These criteria include source and destination address, protocol, port type, and Differentiated Services (DS/TOS) byte.
List of Profiles:
0: New Profile
Enter a Name (1-29 characters) for this Profile []? 32-106 1
Source Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]? 2
Enter IPV4 Source Address [192.168.141.32]?
Enter IPV4 Source Mask [255.255.255.240]?
Destination Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Destination Address [9.24.106.0]?
Enter IPV4 Destination Mask [255.255.255.0]?
Protocol IDs:
1) TCP
2) UDP
3) All Protocols
4) Specify Range
Select the protocol to filter on (1-4) [3]? 3
Enter the Starting value for the Source Port [0]?
Enter the Ending value for the Source Port [65535]?
Enter the Starting value for the Destination Port [0]?
Enter the Ending value for the Destination Port [65535]?
Enter the Mask to be applied to the Received DS-byte [0]? 4
Enter the value to match against after the Mask has
been applied to the Received DS-byte [0]?
Configure local and remote ID's for ISAKMP? [No]: YES 5
Enter local identification to send to remote
1) Local Tunnel Endpoint Address
2) Fully Qualified Domain Name
3) User Fully Qualified Domain Name
4) Key ID (any string)
Select the Identification type (1-4) [1]?
Any user within profile definition allowed access? [Yes]:
Limit this profile to specific interface(s)? [No]:
...continued on next screen
|
Table 20-5. Confirm the Profile
Here is the Profile you specified...
Profile Name = 32->106
sAddr:Mask= 192.168.141.32: 255.255.255.240 sPort= 0 : 65535
dAddr:Mask= 9.24.106.0 : 255.255.255.0 dPort= 0 : 65535
proto = 0 : 255
TOS = x00 : x00
Remote Grp=All Users
Is this correct? [Yes]:
List of Profiles:
0: New Profile
1: 32->106
Enter number of the profile for this policy [1]? 1
|
The validity period is the time period during which the policy is valid. You may configure the validity period to specify a time duration or the months of the year, days of the week and hours of the day that the policy is valid. This flexibility enables the network administrator to specify when a policy is valid. For example, requirements could be "all the time" or "only this year during January and February" or "only Monday through Friday 9AM to 5PM." These requirements can be translated to configuration values using the Add Validity Period command.
Table 20-6. Add the Validity Period
List of Validity Periods: 1
0: New Validity Period
Enter number of the validity period for this policy [0]?
Enter a Name (1-29 characters) for this Policy Valid Profile []? always
Enter the lifetime of this policy. Please input the
information in the following format:
yyyymmddhhmmss:yyyymmddhhmmss OR '*' denotes forever.
[*]? *
During which months should policies containing this profile
be valid. Please input any sequence of months by typing in
the first three letters of each month with a space in between
each entry, or type ALL to signify year round.
[ALL]?
During which days should policies containing this profile
be valid. Please input any sequence of days by typing in
the first three letters of each day with a space in between
each entry, or type ALL to signify all week
[ALL]?
Enter the starting time (hh:mm:ss or * denotes all day)
[*]?
Here is the Policy Validity Profile you specified...
Validity Name = always 2
Duration = Forever
Months = ALL
Days = ALL
Hours = All Day
Is this correct? [Yes]:
List of validity periods:
0: New Validity Period
1: always
Enter number of the validity period for this policy [1]?
|
In addition to a profile and a validity period, a policy must also be associated with either an IPSec action, a Manual IPsec or a DiffServ Action. In this scenario, an IPSec action is configured.
An IPSec action may specify either a drop, pass or secure action. If the action is drop, then all packets matching the profile used by this policy are dropped. If the action is pass with no security, then all packets are passed in the clear. If the action is pass with security, then all packets are secured by means of the SA specified by this action. The IPSec action also contains the IP addresses of the tunnel endpoints for the IPSec tunnel and IKE SAs.
Table 20-7. Add the IPSec Action
Should this policy enforce an IPSEC action? [No]: y
IPSEC Actions:
0: New IPSEC Action
Enter the Number of the IPSEC Action [0]?
Enter a Name (1-29 characters) for this IPsec Action []? tunnel_vpnrtr1-vpnrtr2
List of IPsec Security Action types:
1) Block (block connection)
2) Permit
Select the Security Action type (1-2) [2]?
Should the traffic flow into a secure tunnel or in the clear:
1) Clear
2) Secure Tunnel
[2]?
Enter Tunnel Start Point IPV4 Address
[192.168.141.18]?
Enter Tunnel End Point IPV4 Address (0.0.0.0 for Remote Access)
[0.0.0.0]? 192.168.141.17
Does this IPSEC tunnel flow within another IPSEC tunnel? [No]: 1
Percentage of SA lifesize/lifetime to use as the acceptable minimum [75]?
Security Association Refresh Threshold, in percent (1-100) [85]?
Options for DF Bit in outer header (tunnel mode): 2
1) Copy
2) Set
3) Clear
Enter choice (1-3) [1]?
Enable Replay prevention (1=enable, 2=disable) [2]? 3
Do you want to negotiate the security association at
system initialization(Y-N)? [No]: y 4
|
Figure 20-4. Tunnel in a Tunnel
 View figure. |
All traffic going between RTR-A and RTR-C should be authenticated, but all traffic between RTR-A and RTR-B must be encrypted. The distinction of tunnel-in-tunnel is that tunnels start at the same point but finish at different points. For this example, the answer is no.
Figure 20-5. Understanding the DF Bit
 View figure. |
The traffic is flowing from the device on the left to the device on the right. RTR-2 needs to fragment the packet but cannot do so because the DF bit is set. RTR-2 will generate an ICMP packet too big message and send it to the sender of the packet, RTR-1. RTR-1 then needs to inform the sender that the packet is too large. This can cause problems for RTR-1 because either (a) the ICMP packet might not contain enough of the original packet to be able to determine who the sender is or (b) the IP address might be encrypted. If RTR-1 cannot determine who the sender is, he will store tunnel information and wait for another packet to arrive for that tunnel. When that packet arrives, RTR-1 will then generate the ICMP packet too big message if necessary. So consider carefully the setting of the DF bit.
In this example, we have set the DF bit to copy (the default).
Following this step we are prompted to select an IPSec proposal. Since no previous proposal exists, the only option is to create a new one.
The IPSec proposal contains the information about which ESP, AH, (or both) transform to propose or check against during phase 2 ISAKMP negotiations. Refer to IKE for an explanation of phase 2 negotiations. If you require pfs (perfect forward secrecy), then the IPSec proposal identifies which DH (Diffie-Hellman) group to use. The transforms that the IPSec proposal references are sent or checked against the order in which they are specified. The first ESP or AH transform in the list must be the one that is most appropriate to use. If more than one transform is in the list, then each one is compared to the peer's list of transforms to find a match. If none of the configured transforms match the peer's list, then the negotiation fails. The IPSec proposal may list a combination of AH and ESP transforms, but the only valid combinations are:
Table 20-8. Adding the IPSec Proposal
You must choose the proposals to be sent/checked against during phase 2
negotiations. Proposals should be entered in order of priority.
List of IPSEC Proposals: 1
0: New Proposal
Enter the Number of the IPSEC Proposal [0]?
Enter a Name (1-29 characters) for this IPsec Proposal []? esp-prop1
Does this proposal require Perfect Forward Secrecy?(Y-N)? [No]:
Do you wish to enter any AH transforms for this proposal? [No]:
Do you wish to enter any ESP transforms for this proposal? [No]: y 2
|
The attributes of the IPSec transform contain information about the IPSec encryption and authentication parameters and also specify how often the keys are refreshed. The transform is either AH (authentication only) or ESP (encryption, authentication, or both) and may be configured to operate in either tunnel or transport mode.
Table 20-9. Add the IPSec Transform
List of ESP Transforms:
0: New Transform
Enter the Number of the ESP transform [0]?
Enter a Name (1-29 characters) for this IPsec Transform []? esp-trans1
List of Protocol IDs:
1) IPSEC AH
2) IPSEC ESP
Select the Protocol ID (1-2) [1]? 2
List of Encapsulation Modes:
1) Tunnel 1
2) Transport
Select the Encapsulation Mode(1-2) [1]?
List of IPsec Authentication Algorithms: 2
0) None
1) HMAC-MD5
2) HMAC_SHA
Select the ESP Authentication Algorithm (0-2) [2]?
List of ESP Cipher Algorithms:
1) ESP DES
2) ESP 3DES
3) ESP CDMF
4) ESP NULL
Select the ESP Cipher Algorithm (1-4) [1]? 3
Security Association Lifesize, in kilobytes (1024-65535) [50000]? 4
Security Association Lifetime, in seconds (120-65535) [3600]?
Here is the IPSec transform you specified...
Transform Name = esp-trans1
Type =ESP Mode =Tunnel LifeSize= 50000 LifeTime= 3600
Auth =SHA Encr =DES
Is this correct? [Yes]: y
List of ESP Transforms:
0: New Transform
1: esp-trans1
Enter the Number of the ESP transform [1]?
Do you wish to add another ESP transform to this proposal? [Yes]: n
|
After adding the IPSec transform, you are prompted to confirm the IPSec Proposal.
Table 20-10. Confirm the IPSec Proposal
Here is the IPSec proposal you specified...
Name = esp-prop1
Pfs = N
ESP Transforms:
esp-trans1
Is this correct? [Yes]: y
List of IPSEC Proposals:
0: New Proposal
1: esp-prop1
Enter the Number of the IPSEC Proposal [1]?
Are there any more Proposal definitions for this IPSEC Action? [No]:
|
After the IPSec transform and proposal are created, we can finish the IPSec Action. We are given a confirmation screen and prompted to select the action to be associated with the policy.
Table 20-11. Confirm the IPSec Action
Here is the IPSEC Action you specified...
IPSECAction Name = tunnel_vpnrtr1-vpnrtr2
Tunnel Start:End = 192.168.141.18 : 192.168.141.17
Tunnel In Tunnel = No
Min Percent of SA Life = 75
Refresh Threshold = 85 %
Autostart = Yes
DF Bit = COPY
Replay Prevention = Disabled
IPSEC Proposals:
esp-prop1
Is this correct? [Yes]:
IPSEC Actions:
0: New IPSEC Action
1: tunnel_vpnrtr1-vpnrtr2
Enter the Number of the IPSEC Action [1]?
|
Since a secure IPSec action was specified, you are automatically prompted to create an ISAKMP action. In most cases, one ISAKMP action and one ISAKMP proposal is sufficient for all security policies. The algorithms and methods that you select will most likely be strategic, enterprise-wide parameters. For example, your company will make a decision based on corporate security requirements such as choosing between maximizing encryption levels or striking a balance between privacy and performance. As with any security design, your original configuration should be audited and monitored to insure that it is properly supporting your intentions. The ISAKMP action specifies the key management information for phase I. Refer to IKE for an explanation of the phase I and phase II negotiations.
Table 20-12. Add the ISAKMP Action
ISAKMP Actions:
0: New ISAKMP Action
Enter the Number of the ISAKMP Action [0]?
Enter a Name (1-29 characters) for this ISAKMP Action []? ike-1
List of ISAKMP Exchange Modes: 1
1) Main
2) Aggressive
Enter Exchange Mode (1-2) [1]?
Percentage of SA lifesize/lifetime to use as the acceptable minimum [75]?
ISAKMP Connection Lifesize, in kilobytes (100-65535) [5000]? 2
ISAKMP Connection Lifetime, in seconds (120-65535) [30000]?
Do you want to negotiate the security association at
system initialization(Y-N)? [Yes]: 3
|
The ISAKMP proposal specifies the encryption and authentication attributes of the phase I SA. It also specifies which DH group to use to generate the keys and the life of the phase I security.
Table 20-13. Add the ISAKMP Proposal (Screen 1 of 2)
You must choose the proposals to be sent/checked against during phase 1
negotiations. Proposals should be entered in order of priority.
List of ISAKMP Proposals:
0: New Proposal
Enter the Number of the ISAKMP Proposal [0]? 0
Enter a Name (1-29 characters) for this ISAKMP Proposal []? ike-prop1
List of Authentication Methods:
1) Pre-Shared Key
2) RSA SIG
Select the authentication method (1-2) [1]? 1
List of Hashing Algorithms:
1) MD5
2) SHA
Select the hashing algorithm(1-2) [1]? 1
List of Cipher Algorithms:
1) DES
2) 3DES
Select the Cipher Algorithm (1-2) [1]? 1
...continued
|
Table 20-14. Add the ISAKMP Proposal (Screen 2 of 2)
Security Association Lifesize, in kilobytes (100-65535) [1000]?
Security Association Lifetime, in seconds (120-65535) [15000]?
List of Diffie Hellman Groups:
1) Diffie Hellman Group 1
2) Diffie Hellman Group 2
Select the Diffie Hellman Group ID from this proposal (1-2) [1]? 1
Here is the ISAKMP Proposal you specified...
Name = ike-prop1
AuthMethod = Pre-Shared Key
LifeSize = 1000
LifeTime = 15000
DHGroupID = 1
Hash Algo = MD5
Encr Algo = DES CBC
Is this correct? [Yes]:
List of ISAKMP Proposals:
0: New Proposal
1: ike-prop1
Enter the Number of the ISAKMP Proposal [1]?
Are there any more Proposal definitions for this ISAKMP Action? [No]:
|
Once all of the objects necessary for a secure tunnel policy have been created, a summary of the policy is presented. The defined policy--ike-pre-32-106--has a priority of 15 and will set up a secure tunnel between the 192.168.141.32 subnet and the 9.24.106.0 subnet. The IPSec action specifies a secure tunnel which will always be in effect as specified by the valid period. The packets allowed to enter the tunnel are determined by the profile which describes the two subnets. The authentication and encryption methods are specified in the ISAKMP action and ISAKMP proposal.
Table 20-15. Confirm the ISAKMP Action
Here is the ISAKMP Action you specified...
ISAKMP Name = ike-1
Mode = Main
Min Percent of SA Life = 75
Conn LifeSize:LifeTime = 5000 : 30000
Autostart = Yes
ISAKMP Proposals:
ike-prop1
Is this correct? [Yes]: y
ISAKMP Actions:
0: New ISAKMP Action
1: ike-1
Enter the Number of the ISAKMP Action [1]?
|
After confirming the ISAKMP Action and Proposal, you may wish to configure a DiffServ Action. In that case, a summary of the policy is presented for confirmation.
Table 20-16. Confirm the Policy
Do you wish to Map a DiffServ Action to this Policy? [No]:
Policy Enabled/Disabled (1. Enabled, 2. Disabled) [1]?
Here is the Policy you specified...
Policy Name = ike-pre-32-106
State:Priority =Enabled : 15
Profile =32-106
Valid Period =always
IPSEC Action =tunnel_vpnrtr1-vpnrtr2
ISAKMP Action =ike-1
Is this correct? [Yes]: Y
|
This policy will evaluate all packets entering the router and forward those packets matching the profile to IPSec for encryption. If no further policies are created, then all packets not matching the profile will be routed in the clear to the appropriate interface.
However, for the purpose of this scenario, only traffic between the two subnets should cross the VPN. To accomplish this, a policy to drop all traffic that does not come from one of the two specified subnets will have to be created.
These are the steps to create the policy to drop public traffic that is not from either of the subnets specified in the IPSec tunnel policy. The steps to configure this policy are similar to the tunnel policy except there are fewer steps:
Table 20-17. Add Policy to Drop Public Traffic
VPNRTR1 Config>FEATURE Policy IP Network Policy configuration VPNRTR1 Policy config>ADD POLICY Enter a Name (1-29 characters) for this Policy []? dropAllPublicTraffic Enter the priority of this policy (This number is used to determine the policy to enforce in the event of policy conflicts) [5]? 1 |
This profile is designed to match all traffic.
Table 20-18. Add Policy to Match All Traffic
List of Profiles:
0: New Profile
1: 32->106
Enter number of the profile for this policy [1]? 0
Enter a Name (1-29 characters) for this Profile []? allPublicTraffic
Source Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Source Address [0.0.0.0]?
Enter IPV4 Source Mask [0.0.0.0]?
Destination Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Destination Address [0.0.0.0]?
Enter IPV4 Destination Mask [0.0.0.0]?
Protocol IDs:
1) TCP
2) UDP
3) All Protocols
4) Specify Range
Select the protocol to filter on (1-4) [3]?
Enter the Starting value for the Source Port [0]?
Enter the Ending value for the Source Port [65535]?
Enter the Starting value for the Destination Port [0]?
Enter the Ending value for the Destination Port [65535]?
Enter the Mask to be applied to the Received DS-byte [0]?
Enter the value to match against after the Mask has
been applied to the Received DS-byte [0]?
Configure local and remote ID's for ISAKMP? [No]:
|
Since no source and destination IP Addresses were specified, which interfaces the policy applies to must be specified.
Table 20-19. Define Interfaces to Block Public Traffic
The Source and/or Destination Address information you specified
includes all addresses. You must specify an Interface Pair
with this profile to further qualify what traffic you wish to filter
to this policy.
Limit this profile to specific interface(s)? [No]: yes
Interface Pair Groups:
0: New Ifc Pair
Number of Ifc Pair Group [1]? 0
Enter a Group Name (1-29 characters) for this Interface Pair []? inOutPublic
Ingress Interface IP Address (255.255.255.255 = any ingress)
[255.255.255.255]?
Egress Interface IP Address (255.255.255.255 = any egress)
[255.255.255.255]? 192.168.141.18
Interface Pair Groups:
0: New Ifc Pair
1) Group Name: inOutPublic
In:Out=255.255.255.255 : 192.168.141.18
|
Table 20-20. Verify Specified Interfaces
Number of Ifc Pair Group [1]? 0
Enter a Group Name (1-29 characters)for this Interface Pair []?inOutPublic
Ingress Interface IP Address (255.255.255.255 = any ingress)
[255.255.255.255]? 192.168.141.18
Egress Interface IP Address (255.255.255.255 = any egress)
[255.255.255.255]?
Interface Pair Groups:
0: New Ifc Pair
1) Group Name: inOutPublic
In:Out=255.255.255.255 : 192.168.141.18
In:Out= 192.168.141.18 : 255.255.255.255
Number of Ifc Pair Group [1]? 1
Here is the Profile you specified...
Profile Name = allPublicTraffic
sAddr:Mask= 0.0.0.0 : 0.0.0.0 sPort= 0 : 65535 1
dAddr:Mask= 0.0.0.0 : 0.0.0.0 dPort= 0 : 65535 2
proto = 0 : 255
TOS = x00 : x00 3
Remote Grp=All Users
1. In:Out=255.255.255.255 : 192.168.141.18
2. In:Out= 192.168.141.18 : 255.255.255.255
Is this correct? [Yes]:
|
Once the interfaces are specified, the profile and the validity period must be selected. A new validity period does not need to be created since the previous configured always description can be used.
Table 20-21. Reuse the ALWAYS Validity Period
List of Profiles:
0: New Profile
1: 32->106
2: allPublicTraffic
Enter number of the profile for this policy [1]? 2
List of Validity Periods:
0: New Validity Period
1: always
Enter number of the validity period for this policy [1]? 1
|
Describe a security action to drop all traffic that matches the allPublicTraffic profile. The fact that this policy is set at a lower priority than the tunnel policy will cause the correct traffic to enter the tunnel and all other traffic to be dropped. In other words, each incoming packet is tested against the tunnel profile first and against the public profile last.
Table 20-22. Add the IPSec Action to Drop Public Traffic
Should this policy enforce an IPSEC action? [No]: yes
IPSEC Actions:
0: New IPSEC Action
1: tun-32->106
Enter the Number of the IPSEC Action [1]? 0
Enter a Name (1-29 characters) for this IPsec Action []? dropTraffic
List of IPsec Security Action types:
1) Block (block connection)
2) Permit
Select the Security Action type (1-2) [2]? 1
Here is the IPSec Action you specified...
IPSECAction Name = dropTraffic
Action = Drop
Is this correct? [Yes]: yes
IPSEC Actions:
0: New IPSEC Action
1: tun-32->106
2: dropTraffic
Enter the Number of the IPSEC Action [1]? 2
Do you wish to Map a DiffServ Action to this Policy? [No]:
Policy Enabled/Disabled (1. Enabled, 2. Disabled) [1]? 1
|
Confirm the policy by entering Yes.
Table 20-23. Confirm the Policy to Drop Traffic
Here is the Policy you specified...
Policy Name = dropAllPublicTraffic
State:Priority =Enabled : 1
Profile =allPublicTraffic
Valid Period =always
IPSEC Action =dropTraffic
Is this correct? [Yes]: Y
|
This completes the configuration on VPNRTR1. Be sure to make a copy of the configuration in IBD, the configuration program, or send to a TFTP server.
Refer to Figure 20-2 for the network diagram and IP addresses for this example. These are the steps to configure the router:
The steps for creating the VPNRTR2 policy are the same as those for VPNRTR1 with the following differences:
| Note: | Make sure that the pre-shared key is identical in both routers. An easy way to do this is to cut and paste the keys. Also, be aware that if the key entered is longer than the character width of the Telnet session screen, you may not see the entire key when the confirmation screen is presented. |
Table 20-24 shows the output of the Talk 6 list all command after completing the configuration of VPNRTR2. The values that are different from the VPNRTR1 policy are annotated below each figure.
Table 20-24. List All of the Policy Database Objects for VPNRTR2
VPNRTR2 Policy config>LIST ALL
Configured Policies....
Policy Name = ike-pre-106->32 1
State:Priority =Enabled : 15
Profile =106->32 2
Valid Period =always
IPSEC Action =ike-1
ISAKMP Action =ike-1
Policy Name = dropAllPublicTraffic
State:Priority =Enabled : 5
Profile =allPublicTraffic
Valid Period =always
IPSEC Action =dropTraffic
Configured Profiles....
Profile Name = 106->32 3
sAddr:Mask= 9.24.106.0 : 255.255.255.0 sPort= 0 : 65535
dAddr:Mask= 192.168.141.32 : 255.255.255.240 dPort= 0 : 65535
proto = 0 : 255
TOS = x00 : x00
|
Table 20-25. List Policy Database Objects for VPNRTR2 (Screen 1 of 4)
Remote Grp=All Users
Profile Name = allPublicTraffic
sAddr:Mask= 0.0.0.0 : 0.0.0.0 sPort= 0 : 65535
dAddr:Mask= 0.0.0.0 : 0.0.0.0 dPort= 0 : 65535
proto = 0 : 255
TOS = x00 : x00
Remote Grp=All Users
1. In:Out=255.255.255.255 : 192.168.141.17 1
2. In:Out= 192.168.141.17 : 255.255.255.255
Configured Validity Periods
Validity Name = always
Duration = Forever
Months = ALL
Days = ALL
Hours = All Day
Configured DiffServ Actions....
No DiffServ Actions configured
|
Table 20-26. List Policy Database Objects for VPNRTR2 (Screen 2 of 4)
Configured IPSEC Actions....
IPSECAction Name = ike-1
Tunnel Start:End = 192.168.141.17 : 192.168.141.18 1
Tunnel In Tunnel = No
Min Percent of SA Life = 75
Refresh Threshold = 85 %
Autostart = No
DF Bit = COPY
Replay Prevention = Disabled
IPSEC Proposals:
esp-prop1
IPSECAction Name = dropTraffic
Action = Drop
Configured IPSEC Proposals....
Name = esp-prop1
Pfs = N
ESP Transforms:
esp-trans1
|
Table 20-27. List Policy Database Objects for VPNRTR2 (Screen 3 of 4)
Configured IPSEC Transforms....
Transform Name = esp-trans1
Type =ESP Mode =Tunnel LifeSize= 50000 LifeTime= 3600
Auth =SHA Encr =DES
Configured ISAKMP Actions....
ISAKMP Name = ike-1
Mode = Main
Min Percent of SA Life = 75
Conn LifeSize:LifeTime = 5000 : 30000
Autostart = Yes
ISAKMP Proposals:
ike-prop1
|
Table 20-28. List Policy Database Objects for VPNRTR2 (Screen 4 of 4)
Configured ISAKMP Proposals....
Name = ike-prop1
AuthMethod = Pre-Shared Key
LifeSize = 1000
LifeTime = 15000
DHGroupID = 1
Hash Algo = MD5
Encr Algo = DES CBC
Configured Policy Users....
Name = 192.168.141.18 1
Type = IPV4 Addr
Group =
Auth Mode =Pre-Shared Key
Key(Ascii)=key
Configured Manual IPSEC Tunnels....
IPv4 Tunnels
------------------------------------------------------------------------------
ID Name Local IPv4 Addr Rem IPv4 Addr Mode State
------ --------------- --------------- --------------- ----- --------
VPNRTR2 Policy config>
|
These are the steps to create the policy to drop public traffic that is not from either of the subnets specified in the IPSec tunnel policy.
| Note: | For exact, step-by-step instructions, refer to Create a Policy on VPNRTR1 to Drop Public Traffic. The only difference is in the Specify the Interfaces step where the interface address will be the IP Address of the WAN port for VPNRTR2. |
The policy database takes the policy and generates the rules which are needed for IPSec. The policy has defined that traffic going from x.x.x.x to x.x.x.x need to be secured using tunnel tunnelname. In the past, packet filters would also need to be configured to confirm that traffic from x.x.x.x to x.x.x.x had been secured by tunnel tunnelname. The policy feature creates this filter for you. If you want to know what policies have been generated, go into the policy feature from talk 5 and enter list policy generated. The router will list all the policies that you have defined. Select the appropriate number, and the router will tell you what rules were generated for that policy.
Table 20-29. List the Policy Generated
VPNRTR2 *TALK 6 VPNRTR2 Config>FEATURE Policy IP Network Policy configuration VPNRTR2 Policy console>LIST POLICY GENERATED 1: (Enabled,Valid) dropAllPublicTraffic 2: (Enabled,Valid) ike-pki-106-32 Number of Policy to display [0]? 2 Rules generated for policy ike-pki-106-32: Rule 1. ike-pki-106-32.p1in Rule 2. ike-pki-106-32.p1out Rule 3. ike-pki-106-32.p2in Rule 4. ike-pki-106-32.traffic Rule 5. ike-pki-106-32.inBoundTunnel |
If you want to know what these rules are, there are two commands: one gives you a summary and one gives you the details. List rule basic gives you the basic information about a rule--the priority, how it was generated and how it has been used.
VPNRTR2 Policy console>LIST RULE BASIC 1: (Enabled,Valid) ike-pki-106-32.p2in 2: (Enabled,Valid) ike-pki-106-32.p1out 3: (Enabled,Valid) ike-pki-106-32.p1in 4: (Enabled,Valid) ike-pki-106-32.traffic 5: (Enabled,Valid) ike-pki-106-32.inBoundTunnel 11: (Enabled,Valid) dropAllPublicTraffic Number of Rule to display (0 for All) [0]? 1 Policy Name: ike-pki-106-32.p2in Loaded from: Local State: Enabled and Valid Priority: 94 Hits: 0 Profile: 106->32.p2in Validity: always IPSEC: ike-1 |
List rule complete shows you the details of the rule. This rule is used to confirm that traffic from 192.168.141.18 to 192.168.141.17 was secured using the correct tunnel definition.
Table 20-31. List Rule Complete
VPNRTR2 Policy console>LIST RULE COMPLETE
1: (Enabled,Valid) ike-pki-106-32.p2in
2: (Enabled,Valid) ike-pki-106-32.p1out
3: (Enabled,Valid) ike-pki-106-32.p1in
4: (Enabled,Valid) ike-pki-106-32.traffic
5: (Enabled,Valid) ike-pki-106-32.inBoundTunnel
11: (Enabled,Valid) dropAllPublicTraffic
Number of Rule to display (0 for All) [0]? 1
Policy name: ike-pki-106-32.p2in
Policy Loaded from: Local Configuration
Policy state: Enabled and Valid
Policy Priority: 94
Profile Name = 106->32.p2in
sAddr:End = 192.168.141.18 : 192.168.141.18 sPort= 500 : 500
dAddr:End = 192.168.141.17 : 192.168.141.17 dPort= 500 : 500
proto = 17 : 17
TOS = x00 : x00
Remote Grp=All Users
Validity Name = always
Duration = Forever
Months = ALL
Days = ALL
Hours = All Day
IPSECAction Name = ike-1
Tunnel Start:End = 192.168.141.17 : 192.168.141.18
Tunnel In Tunnel = No
Min Percent of SA Life = 75
Refresh Threshold = 85 %
Autostart = No
DF Bit = COPY
Replay Prevention = Disabled
IPSEC Proposals:
----------------
1:Name = esp-prop1
Pfs = N
ESP Transforms:
--------------
1:Name = esp-trans1
Mode = Tunnel
LifeSize = 50000
LifeTime = 3600
Authent = SHA Encr =DES
VPNRTR2 Policy console>
|
Other useful commands:
If you are going to perform authentication using digital certificates you will need to have a certificate authority (CA). This is typically a software package running on a PC or UNIX platform. Note that in this release only one CA is supported, so all of your certificates for the entire network have to be issued by the same instance of the software package. Many companies sell CA software--for example, Entrust Technologies, Inc. and VeriSign.
To obtain a certificate, the router must have a private and public key. These are generated when the certificate request is issued from talk 5. Once the keys are generated, the router forms a certificate-request packet. This contains the router's public key and an identifier. The request is then sent to a TFTP server running somewhere in the network. The certificate-request must then be passed to CA and be read and processed by the CA. The CA will issue a certificate. The certificate contains the router's public key, the identifier sent by the router and a validity period. The certificate is signed by the CA's private key.
The router must then retrieve this certificate, either via TFTP or via LDAP. When the router downloads the certificate, the private key that is the partner to the public key in the certificate must still be in the router's running memory. The downloaded certificate is useless if the router has lost its matching private key. This means that from the time you issue the certificate request to the time the certificate downloads, you must not restart or reload the router, clear the cache, or issue a new certificate request. Any of these operations destroy the private key. The keys and certificate should be saved as soon as the certificate has been retrieved.
The router also needs to have a copy of the CA's certificate. When the router verifies a peer's certificate, it must confirm that the peer's certificate was signed by the CA's private key. To be able to do this, it must have the CA's certificate which contains the CA's public key. Each router performing IKE must download the CA's certificate using either TFTP or LDAP. This certificate must also be saved.
This example explains how to configure IBM routers for IP security with automatic key negotiations using digital signatures to provide authentication. The tunnel is from router to router. This tunnel will authenticate and encrypt traffic from specific hosts and will exclude all other traffic. The profile describes exactly which hosts at either end of the tunnel are allowed to pass data through the tunnel. The policy can allow a single host on either end, single or multiple subnets on either end, or any combination of the two. The limitation of router to router tunneling is that no authentication or encryption occurs on the LAN. This solution does not provide security on the LAN.
Refer to Figure 20-1 for the physical network connectivity. Refer to Figure 20-2 for the logical network diagram and IP Addressing. Documentation and screen captures will be given for only the parameters that are different from the example in IPSec Router to Router VPN Using Pre-Shared Keys.
| Note: | A user does not need to be defined in this case. The authentication will be provided by the digital certificate. |
The steps for this example will be very similar to those described in Create a Policy for the IPSec Tunnel for VPNRTR1. To create this configuration, begin with the step titled Enable IPSecurity and continue the steps exactly until the end of the step titled Add ISAKMP Action. The next step, Add ISAKMP Proposal, will be different.
Except as noted in the following steps, these steps are the same as for the pre-shared keys example given in Create a Policy for the IPSec Tunnel for VPNRTR1. When using this method, do not use the Add User command to create a user and the keys. When creating the profile, you can configure it the same as the previous example, but be sure to consider the note.
| Note: | When adding the profile, you are prompted to configure IDs for ISAKMP. You must do this so that the other peer can identify you. The method chosen here must match the subject-alt-name type and information entered in the CERT-REQ command shown in Table 20-34. The information must also match what is sent to the Certificate Authority as shown in Figure 20-7. |
The following steps will be different than those in the pre-shared keys example. You will begin by adding a new ISAKMP Proposal to specify the authentication method RSA SIG. RSA SIG is a term for digital certificates. Next, you will request and load a router certificate and a CA certificate.
The ISAKMP proposal specifies the encryption and authentication attributes of the phase I SA. It also specifies which Diffie-Hellman group to use to generate the keys and the life of the phase I security.
Table 20-32. Add the ISAKMP Proposal for Digital Certificates
VPNRTR1 Policy config>ADD ISAKMP-PROPOSAL
Enter a Name (1-29 characters) for this ISAKMP Proposal []? cert1 1
List of Authentication Methods: 2
1) Pre-Shared Key
2) RSA SIG
Select the authentication method (1-2) [1]? 2
List of Hashing Algorithms:
1) MD5
2) SHA
Select the hashing algorithm(1-2) [1]?
List of Cipher Algorithms:
1) DES
2) 3DES
Select the Cipher Algorithm (1-2) [1]?
Security Association Lifesize, in kilobytes (100-65535) [1000]?
Security Association Lifetime, in seconds (120-65535) [15000]?
List of Diffie Hellman Groups:
1) Diffie Hellman Group 1
2) Diffie Hellman Group 2
Select the Diffie Hellman Group ID from this proposal (1-2) [1]?
Here is the ISAKMP Proposal you specified...
Name = cert1
AuthMethod = RSA SIG
LifeSize = 1000
LifeTime = 15000
DHGroupID = 1
Hash Algo = MD5
Encr Algo = DES CBC
Is this correct? [Yes]:
|
The Load Certificate command requires that a TFTP server be pre-defined. Use the Add Server command to assign a name and IP address. It is a good idea to check connectivity between the router and the TFTP sever before attempting the load certificate operation.
Table 20-33. Add the TFTP Server Description for Loading Certificates
VPNRTR1 Config>FEATURE IPSec IP Security feature user configuration VPNRTR1 IPsec config>PKI VPNRTR1 PKI config>ADD SERVER Name ? (max 65 chars) []? TFTPServer Enter server IP Address []? 9.24.106.146 Transport type (Choices: TFTP/LDAP) [TFTP]? VPNRTR1 PKI config>EXIT |
Before requesting a certificate, it is important to make sure the clock of the router to which you will load the certificate is close to but no later than the clock of the CA system. Refer to Chapter 19, "Virtual Private Networks" for an explanation of Certificate Authorities. When a CA issues a certificate, it will be time-stamped with a valid period expressed as beginning and ending time and date. The time of the router must be after the start time of the certificate and before the end time. If the certificate is being issued by a host not under your control, then the only way you can learn the time stamp of the certificate is to request it a try to load it to the router. If the time for the router is outside of the validity period, the following message will be displayed in the ELS log.
PKI.009 Validity check: failed Current date 1999/3/5, Time 9:38.21. Cert valid date: 1999/3/5 10:14:38 -- 1999/6/5 10:14:38
This message informs you that the router time is earlier than the valid certificate time. If this occurs, check the router time using the T 6 command time list to display the time and the command time set to adjust the time.
The CERT-REQ command is used to create a certificate request which will be sent to the CA.
Table 20-34. Request the Certificate
VPNRTR1 *TALK 5 VPNRTR1 +FEATURE IPSec VPNRTR1 IPSP>PKI VPNRTR1 PKI Console>CERT-REQ Enter the following part for the subject name Country Name(Max 16 characters) []? us Organization Name(Max 32 characters) []? cert Organization Unit Name(Max 32 characters) []? Common Name(Max 32 characters) []? VPNRTR1 1 Key modulus size (512|768|1024) [512]? Certificate subject-alt-name type: 2 1--IPv4 Address 2--User FQDN 3--FQDN Select choice [1]? Enter an IPv4 addr) []? 192.168.141.18 3 Generating a key pair. This may take some time. Please wait ... Cert Request format: 1--DER;2--PEM 4 [1]? 2 PKCS10 message successfully generated Enter tftp server IP Address []? 9.24.106.146 Remote file name (max 63 chars) [/tmp/tftp_pkcs10_file]? test.req Memory transfer starting. .Memory transfer completed - successfully. Certificate request TFTP to remote host sucessfully. 5 Generated private key stored into cache Please download router certificate and save both router certificate and its private key ASAP. VPNRTR1 PKI Console> |
The certificate request should be sent to the CA server which will verify the request and issue a certificate. The certificate contains the router public key and the information that you entered. The CA signs the certificate with a private key and it becomes trusted digital information.
Open the test.req document in Word Pad as shown in Figure 20-6.
Figure 20-6. Certificate Request Created by the Router
 View figure. |
For this example, Entrust Technologies was used although you could use any Certificate Authority. The steps to obtain the certificate may be different than the steps listed here.
Remember that when doing a cut and paste, only cut and paste the header and footer and characters in between. The header should begin with dashes and the footer should end with dashes.
On the company's Web Site, select Request a VPN Certificate. Fill out the disclaimer form and click PROCEED. On the next form, scroll down to the input area as shown in Table 20-34, and fill in the common name (which in this example is VPNRTR1). Uncheck the box labeled Encode certificate in PKCS7 certificates only message. Enter the alternative name which should match reference 2 in Table 20-34 for which we entered 192.168.141.18. Delete the pre-entered text in the cut and paste area. Using Word Pad, open the test.req file and cut and paste the certificate request into the window provided on the Web page. The certificate is pasted with no carriage returns.
Figure 20-7. Fill Out the Certificate Request Form
 View figure. |
A certificate will be returned in the Web browser as shown in Figure 20-8.
Figure 20-8. The Router Certificate is Returned to the Browser
 View figure. |
Cut and paste the certificate into a new text document in Word Pad. Delete spaces at the end of the first, next to last, and last line. Save the certificate in the TFTP Server Upload Directory. For this example, the certificate file was named, cert.txt.
The certificate should now be retrieved via LDAP or TFTP. The following scenario uses TFTP to retrieve the certificate. As shown in Table 20-35, use the Load Certificate command to retrieve the router's certificate. Take the default option for the type of certificate since you are retrieving the router's certificate. You are then asked if the certificate is in digital format (option 1) or ASCII format (option 2). Select option 2. Next you are asked for the server name. This is the name of the TFTP server which you added from talk 6. Lastly, you will be asked for the name of the file on the server. The router then retrieves the certificate and stores it in its runtime memory.
Table 20-35. Load the Router Certificate
VPNRTR1 PKI Console>LOAD CERTIFICATE Enter the type of the certificate: Choices: 1-Root CA Cert, 2-Router Cert Enter (1-2): [2]? Encoding format: Choices: 1-DER 2-PEM Enter (1-2): [1]? 2 Server info name []? TFTPServer Remote file name on tftp server (max 63 chars) [/tmp/default_file]? cert.txt Attempting to load certificate file. Please wait ... Memory transfer starting. .Memory transfer completed - succesfully. Router Certificate loaded into run-time cache VPNRTR1 PKI Console> |
Immediately save the certificate and associated keys. You will have to repeat the certificate process if you fail to save the certificate and the router restarts. You will be asked which certificate you are saving, what name you wish to call it and if you wish this certificate to be loaded into the router's memory when the router is started.
Table 20-36. Save the Router Certificate
VPNRTR1 PKI Console>CERT-SAVE
Enter type of certificate to be stored into SRAM:
1)Root certificate;
2)Box certificate with private key;
Select the certificate type (1-2) [2]?
SRAM Name for certificate and private key []? r1cert.txt
Load as default router certificate at initialization? [No]: y
Both Router Certificate and private key saved into SRAM successfully
VPNRTR1 PKI Console>
|
The router now has its private and public keys, which were generated just before the certificate request was issued. You have just retrieved the router's certificate. Now you need the CA's certificate so you can verify the validity of an IKE peer's certificate. One part of confirming the validity is to check that the CA signed the peer's certificate, therefore the CA's certificate is needed. The peer's certificate must be signed by the same CA because there is no mechanism in place to check a certificate issued by another CA.
Next, Retrieve PEM Encoded Certificate was selected on the Entrust Web site. As shown in Figure 20-9, a CA certificate was returned to the browser. For this particular test, no header or footer was sent with the CA certificate.
Figure 20-9. The CA Certificate is Returned to the Web Browser
 View figure. |
For this example, the text following "CA Certificate" was pasted into a new Word Pad text document. No header or footer was sent with the CA certificate. (This may vary depending on how you get the CA certificate.) In order for the router in this example to accept the certificate, the header and footer from the router certificate that was already received had to be pasted into the document and the CA certificate text was pasted in between the header and footer text as shown in Figure 20-10.
Figure 20-10. Add the Header and Footer to the CA Certificate
 View figure. |
Save the certificate as a document in the TFTP server upload directory. For this example, the file was named cert.txt.
The CA's certificate can also be loaded via TFTP using the Load Certificate command and selecting option 1 as the type of certificate.
Table 20-37. Load the Root Certificate to Cache
VPNRTR1 PKI Console>LOAD CERTIFICATE Enter the type of the certificate: Choices: 1-Root CA Cert, 2-Router Cert Enter (1-2): [2]? 1 Encoding format: Choices: 1-DER 2-PEM Enter (1-2): [1]? 2 Server info name []? TFTPServer Remote file name on tftp server (max 63 chars) [/tmp/default_file]? cacert.txt Attempting to load certificate file. Please wait ... Memory transfer starting. .Memory transfer completed - successfully. Root CA Certificate loaded into run-time cache VPNRTR1 PKI Console> |
Table 20-38. Save the Root Certificate to the Router Configuration
VPNRTR1 PKI Console>CERT-SAVE
Enter type of certificate to be stored into SRAM:
1)Root certificate;
2)Box certificate with private key;
Select the certificate type (1-2) [2]? 1
SRAM Name to store Root Certificate? []? cacert
Load as default root certificate at initialization? [No]: y
Root Certificate saved into SRAM successfully.
VPNRTR1 PKI Console>
|
Once you have saved the CA certificate, you have completed configuration of the VPNRTR1 tunnel policy.
The steps to configure this policy are exactly the same as the step in the example shown in Create a Policy on VPNRTR1 to Drop Public Traffic:
This completes the configuration of VPNRTR1. Save copies of the configuration because you will not want to take the time to do this again.
To create the IP Security tunnel, follow these steps:
The steps above are the same as the steps shown in Create a Policy for the IPSec Tunnel for VPNRTR1 with the following differences:
The steps for creating this policy are the same as the steps in Create a Policy on VPNRTR2 to Drop Public Traffic.
Monitoring operations and statistics for this example are the same as for the pre-shared keys example. Refer to Monitoring/Troubleshooting the Policies.
Refer to Point-to-Point Tunneling Protocol for additional information about PPTP.
IBM routers support PPTP in order to provide interoperability with Microsoft Windows devices which support only PPTP. Microsoft has announced intentions to implement L2TP on NT 5.0.
Figure 20-11 is an example of a remote access VPN using PPTP voluntary tunneling. The IBM router will be configured as the endpoint of a PPTP tunnel. The client, a Windows/98, Windows/95 or Windows NT Dial-Up Networking (DUN) client will dial into the ISP router. The client will establish a PPP connection and be given an IP address on the 9.24.104.0 subnet. At this point, the client has IP connectivity to anywhere in the Internet IP cloud including the WAN interface of the corporate Internet router. The client will then establish a tunnel to 192.168.141.18, which is the IP address of the corporate Internet router. The userid and password for the PPTP tunnel is sg245281 and the IP address is 192.168.141.38. These are assigned by the corporate router. Once the tunnel is established, connectivity is the same as you would have if you dialed directly into a Remote Access Server on the corporate LAN.
Figure 20-11. Workstation to Gateway PPTP Tunnel
 View figure. |
Before completing the following steps, make sure the Network Utility has the proper interfaces configured. Also configure IP so that the PPP interface has either a static or dynamic route to the Internet. The Intranet interface should not be advertised on the Internet. Refer to Figure 20-12 for the IP addressing of the network that was used for this example.
Figure 20-12. IP Addressing Scheme
 View figure. |
To configure the corporate Internet router as illustrated in Figure 20-11, follow these steps:
VPNRTR1 *TALK 6 VPNRTR2 Config>FEATURE Layer-2-Tunneling VPNRTR2 Layer-2-Tunneling Config>ENABLE PPTP Restart system for changes to take effect. |
Add the number of Layer 2 Nets needed to support the maximum number of simultaneous connections. In this example, 3 nets are added. You do not need to enable IPX or transparent bridging.
Table 20-40. Add a Layer-2 Net
VPNRTR1 *TALK 6 VPNRTR2 Config>FEATURE Layer-2-Tunneling VPNRTR2 Layer-2-Tunneling Config>ADD L2-NETS Additional L2 nets: [0]? 3 1 Add unnumbered IP addresses for each L2 net? [Yes]: Adding device as interface 6 Defaulting Data-link protocol to PPP Adding device as interface 7 Defaulting Data-link protocol to PPP Adding device as interface 8 Defaulting Data-link protocol to PPP Enable IPX on L2T interfaces?(Yes or [No]): Enable transparent bridging on L2T interfaces?(Yes or [No]): Bridge configuration was not changed. Restart router for changes to take affect. VPNRTR2 Layer-2-Tunneling Config> |
Microsoft Windows Dial-UP Networking (DUN) PPTP clients use MPPE to perform encryption. This protocol needs to be enabled on the L2Net. L2Nets configured as inbound from anyone (the default) take their PPP defaults from a template in the layer feature. The encapsulator command takes you to a prompt from where all the PPP defaults can be tuned.
To use MPPE, you must enable MS-CHAP. When you enable MPPE, you will be asked if MPPE is operating in mandatory or optional mode. If it is operating in mandatory mode, you must negotiate MPPE. Mandatory mode forces the router to renegotiate MPPE each time a new connection is requested, even when the sender has previously established MPPE between itself and the router. If MPPE is operating in optional mode, you are not obligated to negotiate MPPE. Optional mode results in the router maintaining MPPE between itself and the sender after the initial negotiation and does not renegotiate MPPE for each new connection. You will then be asked if the keys are stateful or stateless. If the keys are stateless, the key changes every time a packet is sent, whereas with stateful the key is only generated when 255 packets have been sent. Stateless is advised for lossy networks and should be used for PPTP connections. The router will know if the client is using stateless or stateful mode since part of the MPPE header indicates whether the keys have been refreshed.
Microsoft also has their own compression algorithm, MPPC. MPPE is negotiated as an MPPC option. If you wish to do compression and you are using MPPE, you must use MPPC. In this case, you cannot use the Stac-LZS algorithm which is normally available for PPP links. If you chose not to use MPPC, the router code partially enables the function to allow MPPE to be negotiated. If you do chose to use MPPE and MPPC, they are decoded in one pass since these protocols share the same PPP header.
Table 20-41. Enable MSCHAP and MPPE
VPNRTR1 Layer-2-Tunneling Config>ENCAPSULATOR
Point-to-Point user configuration
VPNRTR1 PPP-L2T Config>ENABLE MSCHAP
Rechallenge Interval in seconds (0=NONE) [0]?
Enabling MSCHAP
VPNRTR1 PPP-L2T Config>ENABLE MPPE
mandatory or optional [optional]?
stateful or stateless [stateful]? stateless 1
Enabling encryption
** Note ** : To view the MPPE configuration, please enter a 'list ccp'
command since MPPE is negotiated within the CCP protocol.
VPNRTR1 PPP-L2T Config>
|
For this example, two users are configured so that at least two simultaneous connections are tested. Each user has been assigned a static IP address. This is the simplest but also the least flexible and least scaleable way to assign IP addresses to PPP clients. Other methods of assigning IP addresses are to use an IP address pool or to use DHCP services.
First the user named sg245281 is added. The password entry will not appear on the screen.
VPNRTR2 Config>ADD PPP-USER
Enter name: []? sg245281
Password:
Enter again to verify:
Allow inbound access for user? (Yes, No): [Yes]
Will user be tunneled? (Yes, No): [No]
Is this a 'DIALs' user? (Yes, No): [Yes]
Type of route? (hostroute, netroute): [hostroute]
Number of days before account expires [0-1000] [0]?
Number of grace logins allowed after an expiration [0-100] [0]?
IP address: [0.0.0.0]? 192.168.141.38 1
Enter hostname: []?
Allow virtual connections? (Yes, No): [No]
Give user default time allotted ? (Yes, No): [Yes]
Enable callback for user? (Yes, No): [No]
Will user be able to dial-out ? (Yes, No): [No]
Set ECP encryption key for this user? (Yes, No): [No]
Disable user ? (Yes, No): [No]
PPP user name: sg245281
User IP address: 192.168.141.38
Netroute Mask: 255.255.255.255
Hostname: Virtual Conn: disabled
Time alotted: Box Default
Callback type: disabled
Dial-out: disabled
Encryption: disabled
Status: enabled
Login Attempts: 0
Login Failures: 0
Lockout Attempts: 0
Account Expiry: Password Expiry:
Is information correct? (Yes, No, Quit): [Yes]
User 'sg245281' has been added
VPNRTR2 Config>
|
Add another ppp user named salesman using the same parameters, and then list all ppp users.
VPNRTR2 Config>LIST PPP-USERS addr List (Name, Verb, User, Addr, VCon, Call, Time, Dial, Encr): [User] addr PPP user name User IP address Netroute Mask Hostname ----------------- ------------------ ------------------ --------------- salesman 192.168.141.39 255.255.255.255 <undefined> sg245281 192.168.141.38 255.255.255.255 <undefined> 2 PPP records displayed. |
Arp subnet routing is also referred to as proxy arp. If a host on the corporate network transmits a datagram to a PPTP host which has an IP address on the same subnet, the sender will not send the datagram to the default route, but will expect to see an entry in its own ARP cache. If there is no entry in the ARP cache, the sender will send ARP broadcasts directed at the destination IP. Since the destination IP address (the remote PPTP client) is not on the physical network, it will never respond. Arp subnet routing allows the local router to respond to the ARP broadcast on behalf of the remote client. The datagram then gets copied by the router and forwarded across the Internet.
Table 20-44. Enable Arp Subnet Routing
VPNRTR2 Config>PROTOCOL Protocol name or number [IP]? Internet protocol user configuration VPNRTR1 IP config>ENABLE ARP-SUBNET-ROUTING VPNRTR1 IP config> |
To establish a PPTP connection using a Microsoft platform, you need two DUN sessions--one to the Internet--the ISP's router--and another to the Network Utility. You will first launch the PPP dial-up connection which establishes the Internet connection, and then launch the PPTP connection to create the tunnel to the Network Utility. The PPP interface of the IBM Network Utility must be accessible on the Internet.
| Note: | You must have DUN 1.2 or later installed. To see if you have Version 1.2 or later, open a Make a New Connection window in the DUN folder. Check for the presence of Microsoft VPN Adapter in the Select a Device drop down window. |
To configure the Microsoft PPTP client, follow these steps:
When using the manually defined ppp-user, you must have a static IP address for each manually configured user.
You can define ppp-user/ip addr for each user and specify on the DUN to use sever assigned IP address. Otherwise, you can have one ppp-user and specify on the DUN to use the locally-assigned static IP address.
In the DUN client under the Properties/Server Type/TCP/IP settings, you can specify whether or not to use the default route on the remote network. What you specify here will depend on whether or not the PPTP client is accessing only resources on the remote subnet or whether it needs to have connectivity to other nets as well.
To verify that the configuration is correct, you can do the following ping tests. First, start the PPP link on the DUN client and ping the Internet interface of the Network Utility. The ping should be successful. Next try to ping the Intranet interface. The ping should fail. Now start the PPTP tunnel by launching the PPTP DUN definition. You should now be able to ping all hosts on the Intranet.
From the Talk 5 prompt, issue the NETWORK 6 command and then the LIST ALL command to see an extensive amount of information about the PPP connection. The most useful for troubleshooting are the statistics, user id, and IP address of the connection.
As shown in Table 20-45, use the CALL STATE command. Before we issued the CALL STATE command, we established sessions with our two ppp-users.
Table 20-45. Display Layer-2 Sessions
VPNRTR1 Layer-2-Tunneling Console> CALL STATE
CallID | Serial # | Net # | State | Time Since Chg | PeerID | TunnelID
55285 | 0 | 8 | Established | 0:37:10 | 0 | 6084
38142 | 0 | 7 | Established | 0: 4:35 | 0 | 24721
VPNRTR1 Layer-2-Tunneling Console>
|
For monitoring and troubleshooting, use the following commands:
In Table 20-46, the output from the TALK 2 command shows the two
PPP nets with the CallID matching the information.
Table 20-46. Output of Talk 2 With Event Set for Display Subsystem L2
00:41:55 L2.024: PPTP PAYLOAD SEND 38 bytes, net=7, callid=38142 00:41:55 L2.041: SND PPTP:F=3081,L=54,Tid=0,Cid=0,NS=115,NR=117,O=0 00:41:55 L2.040: RCV PPTP:F=3081,L=38,Tid=24721,Cid=38142,NS=118,NR=115,O=0 00:41:55 L2.022: PPTP PAYLOAD RCVD 38 bytes, net 7, callid=38142 00:42:00 L2.024: PPTP PAYLOAD SEND 38 bytes, net=8, callid=55285 00:42:00 L2.041: SND PPTP:F=3081,L=54,Tid=0,Cid=0,NS=264,NR=274,O=0 00:42:00 L2.040: RCV PPTP:F=3081,L=38,Tid=6084,Cid=55285,NS=275,NR=264,O=0 00:42:00 L2.022: PPTP PAYLOAD RCVD 38 bytes, net 8, callid=55285 00:42:03 L2.084: PPTP Tunnel 6084/0 EVENT Rcv-ECHO,state=Established |
See Table 20-47 for a partial listing of the LIST ALL command.
Table 20-47. Partial Output of List All Command
VPNRTR1 +NETWORK 8
Point-to-Point Console
VPNRTR1 PPP 8>LIST ALL
Interface Statistic In Out
------------------- -- ---
Packets: 81 70
Octets: 3316 2581
..
.Remote Username: sg245281
.
..IPCP Option Local Remote
----------- ----- ------
IP Address 0.0.0.0 192.168.141.38
Compression Slots None None
|
This example, which is illustrated in Figure 20-13, is a PPTP scenario where the IBM router initiates a PPTP tunnel terminated by a Microsoft NT Remote Access Server (RAS) which is a PPTP peer. The NT server has two adapters--one with an IP address which is reachable via the IP cloud and one on the private network. The NT host does not have a dynamic routing protocol configured, but does have IP forwarding capability.
The scenario will provide connectivity for IP hosts in the branch to hosts on a single subnet within the corporate network. The NT RAS is located in what is sometimes referred to as the DMZ. It is accessible from the Internet and not protected by the corporate firewall. The RAS itself becomes a firewall for the corporate subnet which will be accessed across the Internet.
Figure 20-13. IBM Router Initiated PPTP Tunnel
 View figure. |
The lab network used for this example consists of one PPP link and three token-ring segments connected by two IBM 2210 routers and an NT Workstation. We have named the routers VPNRTR1 and VPNRTR2. The routers in the lab are connected with a 56-Kbps PPP link. In a real scenario, the link between the routers could be any private or public WAN.
Figure 20-14. IP Addressing of Lab Network
 View figure. |
A PPTP tunnel is established when a device on the 9.24.106.0 branch network has data to send to the corporate LAN IP network 192.168.141.64. The 192.168.141.64 network is not advertised into the IP cloud. Hosts on the corporate network are private addresses and the IP cloud is an ISP's network.
VPNRTR2, which represents the Branch Internet Router as illustrated in Figure 20-13, will be configured with a static route that specifies traffic destined for the 192.168.141.64 network and should be routed via the virtual interface. When data is received on the interface, the router will establish a PPTP tunnel. The router examines the L2Net and tunnel definition to locate the IP address of the PPTP peer, 192.168.141.34, which is illustrated as the NT Remote Access Server and VPN Endpoint. The router will establish a TCP connection to this address via the Internet. After the NT has accepted the PPTP connection, the branch router will negotiate the PPP parameters for its L2Net. The NT server will return an IP address from a pool of addresses configured for that PPTP interface. The IP address has to be in the same subnet as the corporate LAN interface. The L2Net must be configured to receive its IP address via IPCP.
Here are the basic steps to configure the branch router:
Enable PPTP on the router and add the virtual interface. When traffic is received on this interface, the router will initiate the PPTP tunnel.
Table 20-48. Add the Layer 2 Networks
VPNRTR2 *TALK 6 VPNRTR2 Config>FEATURE Layer-2-Tunneling VPNRTR2 Layer-2-Tunneling Config>ENABLE PPTP Restart system for changes to take effect. VPNRTR2 Layer-2-Tunneling Config> Layer-2-Tunneling Config>add l2-nets Additional L2 nets: [0]? 1 Add unnumbered IP addresses for each L2 net? [Yes]: Adding device as interface 6 1 Defaulting data-link protocol to PPP Enable IPX on L2T interfaces?(Yes or [No]): Enable transparent bridging on L2T interfaces?(Yes or [No]): Bridge configuration was not changed. Restart router for changes to take affect. Layer-2-Tunneling Config>exit VPNRTR2 Config> |
Table 20-49. List Address to Verify IP Address of PPTP Interface
VPNRTR2 Config>PROTOCOL IP
VPNRTR2 IP config>LIST ADDRESSES
IP addresses for each interface:
intf 0 IP disabled on this interface
intf 1 192.168.141.17 255.255.255.240 Local wire broadcast, fill 1
intf 2 IP disabled on this interface
intf 3 IP disabled on this interface
intf 4 IP disabled on this interface
intf 5 9.24.106.8 255.255.255.0 Local wire broadcast, fill 1
intf 6 0.0.0.6 0.0.0.0 Local wire broadcast, fill 1
DYNAMIC-ADDRESS Enabled
VPNRTR2 Config>EXIT
|
The next step is to define the PPTP tunnel endpoint. The add tunnel-profile command is used to define the tunnel. The name you are prompted for is the name of the remote PPTP. This is only for local identification purposes. It is not sent during the PPTP exchanges. You are asked for the tunnel-server endpoint address--this is in the address of the NT server which is reachable via the IP cloud.
VPNRTR2 Config>ADD TUNNEL-PROFILE
Enter name: []? NT
Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP] PPTP
Tunnel-Server endpoint address: [0.0.0.0]? 192.168.141.34
Tunnel name: NT
TunnType: PPTP
Endpoint: 192.168.141.34
Tunnel 'NT' has been added
|
The next step is to tie our virtual interface to the peer called NT. By default, all L2Nets are inbound from any device. This must be changed to outbound. Then you are prompted for the name of the remote device. This means that when traffic is routed to our virtual interface, interface 6, the router will establish a tunnel to a peer called "NT". It looks at the "NT" tunnel definition and discovers that it is a PPTP tunnel to 192.168.141.34.
The router will look in its routing table to determine how to get to that address, which in this example will be via 192.168.141.17. The router needs to be configured either via static routing or a dynamic routing protocol to know how to get to 192.168.141.34.
Table 20-51. Configure the Virtual Interface
VPNRTR2 Config>NETWORK 6 Session configuration VPNRTR2 L2T config: 6>SET CONNECTION-DIRECTION OUTBOUND 1 Enter remote tunnel hostname: []? NT VPNRTR2 L2T config: 6> |
When an L2Net is changed from inbound to outbound, the PPP defaults can be configured on that L2Net. You can get to PPP configuration prompt by using the encapsulator command. In this example, the router is configured to send the name rtr-1 when prompted. This L2Net is meant to receive its IP address from the NT box. This will be sent during IPCP negotiations, and the router needs to be configured to ask the NT box for its IP address. This can be done using the set ipcp command and answering yes to request an IP address.
Table 20-52. Configure L2net To Send Name and Enable Interface To Receive IP Address Via IPCP
VPNRTR2 Config>NETWORK 6
Session configuration
VPNRTR2 L2T config: 6>ENCAPSULATOR
Point-to-Point user configuration
VPNRTR2 PPP 6 Config>SET NAME
Enter Local Name: []? rtr-1
Password:rtr-1 1
Enter password again:rtr-1
PPP Local Name = rtr-1
VPNRTR2 PPP 6 Config>
VPNRTR2 PPP 6 Config>SET IPCP
IP COMPRESSION [no]:
Request an IP address [no]: yes 2
Interface remote IP address to offer if requested (0.0.0.0 for none) [0.0.0.0]?
VPNRTR2 PPP 6 Config>EXIT
VPNRTR2 L2T config: 6>EXIT
VPNRTR2 Config>
|
In order for the router L2net to receive an IP address from the NT tunnel endpoint, we must enable the IP address for dynamic IP. This will allow the NT to send an address from a pre-configured address pool via IPCP.
Table 20-53. Configure IP on the L2Net
VPNRTR2 Config>PROTOCOL IP Internet protocol user configuration VPNRTR2 IP config>ENABLE DYNAMIC-ADDRESS Interface address []? 0.0.0.6 1 VPNRTR2 IP config> |
A static route to the corporate subnet must be added since no dynamic routing protocols are used on the NT RAS host.
Table 20-54. Add a Static Route to the Private Network
VPNRTR2 IP config>ADD ROUTE IP destination []? 192.168.141.64 1 Address mask [255.255.255.0]? 255.255.255.240 Via gateway 1 at []? 0.0.0.6 Cost [1]? Via gateway 2 at []? VPNRTR2 IP config>EXIT VPNRTR2 Config> |
Since the router is going to appear as a single user on the corporate network, and the corporate network does not have any knowledge of the branch network, we need to use Network Address and Port Translation (NAPT). NAPT is an enhancement to NAT, which was originally shipped in the IBM routers in V3.1. It is enabled and configured from the NAT feature.
VPNRTR2 Config>FEATURE NAT Network Address Translation (NAT) user configuration VPNRTR2 NAT config>ENABLE NAT Complete! NAT set to ENABLED. VPNRTR2 NAT config> |
The next step is to define which address we want the packets translated to. This is done using the reserve command. When it asks you if the address will be obtained via IPCP, the answer is yes. The interface is 6, the L2Net. The router then asks for a pool name. This is used as a reference when we define which addresses should be translated. The router also tells you that you need to configure IP packet filters to pass the packets to the NAT feature to be translated. This is the first time the router reminds you to configure IP packet filters.
Table 20-56. Define How the LAN Addresses Should Be Translated
VPNRTR2 NAT config>RESERVE
Dynamically allocate address via IPCP? [No]: yes
Network number to get dynamic address. [0]? 6
Reserve Pool name..................... []? dyn-nat
Complete! NAT Reserve Pool defined.
NOTE: The associated TRANSLATE RANGE for this RESERVE POOL
must still be configured.
It must have a pool name of: dyn-nat
NOTE: You must have a corresponding INBOUND IP Access Control rule
applied to your designated NAT interface.
The rule should include the following information:
Type=IN (include + NAT)
DESTINATION_Addr=0.0.0.0
DESTINATION_Mask=0.0.0.0
VPNRTR2 NAT config>
|
The next step is to define which addresses should be translated. The command is saying, "Translate all packets with a source address in the 9.24.106.0 network to have an address in the dyn-nat pool." In the previous step, we defined that the dyn-nat pool is the address received by IPCP on interface 6. The router reminds you that you need to configure filters get the packets passed to NAT/NAPT for translation.
Table 20-57. Define Which LAN Addresses Should Be Translated
VPNRTR2 NAT config>TRANSLATE
Base (private) IP address to translate [0.0.0.0]? 9.24.106.0
Translate Range mask.................. [255.255.255.0]?
Associated Reserve Pool name.......... [dyn-nat]?
Complete! NAT Translate Range defined.
NOTE: The associated RESERVE POOL for this TRANSLATE RANGE has been found.
NOTE: You must have a corresponding OUTBOUND IP Access Control rule
applied to your designated NAT interface.
The rule should include the following information:
Type=IN (include + NAT)
SOURCE_Addr=9.24.106.0
SOURCE_Mask=255.255.255.0
VPNRTR2 NAT config>EXIT
VPNRTR2 Config>
|
We now need to create the IP packet filters. Table 20-58 shows that access control is enabled and then the filters attached to the L2Net are created and named out-6 and in-6.
Table 20-58. Add Packet Filters
VPNRTR2 Config>PROTOCOL IP Internet protocol user configuration VPNRTR2 IP config>SET ACCESS-CONTROL ON VPNRTR2 IP config> VPNRTR2 IP config>ADD PACKET-FILTER Packet-filter name []? out-6 Filter incoming or outgoing traffic? [IN]? out Which interface is this filter for [0]? 6 VPNRTR2 IP config>ADD PACKET-FILTER Packet-filter name []? in-6 Filter incoming or outgoing traffic? [IN]? Which interface is this filter for [0]? 6 VPNRTR2 IP config> |
Once the packet filters are created, use the update packet-filter command to define the filters. The purpose of the out-6 filter is to direct all packets that are from subnet 9.24.106.0 and destined for the Internet to the Network Address Translation function.
Table 20-59. Update the Outbound Packet Filter
VPNRTR2 IP config>UPDATE PACKET-FILTER Packet-filter name []? out-6 VPNRTR2 Packet-filter 'out-6' Config>ADD ACCESS-CONTROL Access Control type [E]? N 1 Internet source [0.0.0.0]? 9.24.106.0 Source mask [255.255.255.0]? Internet destination [0.0.0.0]? Destination mask [0.0.0.0]? Starting protocol number ([0] for all protocols) [0]? Starting DESTINATION port number ([0] for all ports) [0]? Starting SOURCE port number ([0] for all ports) [0]? Filter on ICMP Type ([-1] for all types) [-1]? TOS/Precedence filter mask (00-FF - [0] for none) [0]? TOS/Precedence modification mask (00-FF - [0] for none) [0]? Enable logging? [No]: VPNRTR2 Packet-filter 'out-6' Config>exit |
The purpose of the in-6 filter is to direct all packets that are from the Internet and destined for subnet 9.24.106.0 to the Network Address Translation function.
Table 20-60. Update the Inbound Packet Filter
VPNRTR2 IP config>UPDATE PACKET-FILTER Packet-filter name []? in-6 VPNRTR2 Packet-filter 'in-6' Config>ADD ACCESS-CONTROL Access Control type [E]? N Internet source [0.0.0.0]? Source mask [0.0.0.0]? Internet destination [0.0.0.0]? Destination mask [0.0.0.0]? Starting protocol number ([0] for all protocols) [0]? Starting DESTINATION port number ([0] for all ports) [0]? Starting SOURCE port number ([0] for all ports) [0]? Filter on ICMP Type ([-1] for all types) [-1]? TOS/Precedence filter mask (00-FF - [0] for none) [0]? TOS/Precedence modification mask (00-FF - [0] for none) [0]? Enable logging? [No]: VPNRTR2 Packet-filter 'in-6' Config>exit VPNRTR2 IP config>EXIT VPNRTR2 Config> |
This completes the configuration of the branch router. As always, it is a good idea to save the configuration to either the configuration program or a TFTP server.
To configure the NT Remote Access Server, follow these steps:
Add an NT user name rtr-1 and password of rtr-1. This must match the values configured in Table 20-52. Disable the "change password on first logon" option, and set the password to never age.
The NT box must be reachable via the IP cloud. To prevent malicious activity, you can enable PPTP filtering on the interface which is connected to the IP cloud. This means that the PPTP server only accepts PPTP packets from authenticated users. The user, (the remote router in our example), is defined using the "managing users" function within NT. All non-PPTP packets or PPTP traffic from non-authenticated users will be dropped.
Refer to the following Microsoft Web page for information on setting up the PPTP server: http://www.microsoft.com/NTServer/commserv/deployment/planguides/installing_pptp.asp
Use ELS to dynamically monitor the PPTP tunnel. Configure ELS to display only subsystem L2 by issuing the NODISPLAY SUBSYSTEM ALL command followed by the DISPLAY SUBSYSTEM L2 ALL ALL command. Then issue the TALK 2 command as shown in Table 20-61.
Notice that there will be "keepalive" type traffic every 30 seconds even if there is no other traffic.
Table 20-61. ELS Output for L2 Subsystem
VPNRTR2 *TALK 2
40:19:49 L2.024: PPTP PAYLOAD SEND 38 bytes, net=6, callid=55253
40:19:49 L2.041: SND PPTP:F=3081,L=54,Tid=0,Cid=0,NS=121,NR=122,O=0
40:19:49 L2.040: RCV PPTP:F=3081,L=38,Tid=20169,Cid=55253,NS=123,NR=121,O=0
40:19:49 L2.022: PPTP PAYLOAD RCVD 38 bytes, net 6, callid=55253
40:19:59 L2.024: PPTP PAYLOAD SEND 38 bytes, net=6, callid=55253
40:19:59 L2.041: SND PPTP:F=3081,L=54,Tid=0,Cid=0,NS=122,NR=123,O=0
40:19:59 L2.040: RCV PPTP:F=3081,L=38,Tid=20169,Cid=55253,NS=124,NR=122,O=0
40:19:59 L2.022: PPTP PAYLOAD RCVD 38 bytes, net 6, callid=55253
|
For this example, issuing the INTERFACE command at the Talk 5 Protocol IP prompt shows that the PPP/4 interface has been assigned an IP address on the subnet at the other end of the tunnel. Remember that we configured the NT RAS to assign IP addresses from a pool starting at 192.168.141.70 and ending at 192.168.141.73.
The NT RAS host took .70 for its tunnel endpoint address and assigned .71 to the Network Utility at the other tunnel endpoint.
Table 20-62. Display the Interface Information
VPNRTR2 *TALK 5 CGW Operator Console VPNRTR2 + PROTOCOL IP VPNRTR2 IP>INTERFACE Interface MTU IP Address(es) Mask(s) Address-MTU PPP/0 2044 192.168.141.17 255.255.255.240 Unspecified TKR/0 4082 9.24.106.8 255.255.255.0 Unspecified PPP/4 1500 192.168.141.71 255.255.255.255 Unspecified VPNRTR2 IP>EXIT |
Use the call state and call statistics commands at the FEATURE Layer-2-Tunneling prompt as shown in Table 20-63 to verify tunnel activity.
Table 20-63. Display Tunnel Status and Statistics
VPNRTR2 +FEATURE Layer-2-Tunneling Layer-2-Tunneling Information VPNRTR2 Layer-2-Tunneling Console> CALL STATE CallID | Serial # | Net # | State | Time Since Chg | PeerID | TunnelID 64985 | 0 | 6 | Established | 0:13:46 | 0 | 19704 VPNRTR2 Layer-2-Tunneling Console> CALL STATISTICS CallID | Serial # | Tx Pkts | Tx Bytes | Rx Pkts | Rx Bytes | RTT | ATO 64985 | 0 | 95 | 3440 | 97 | 3415 | 0 | 0 VPNRTR2 Layer-2-Tunneling Console> |
| Note: | At the >FEATURE Layer-2-Tunneling, you can use the following sequence of commands: =>T5, =>NET 6, =>LIST ALL. |
Follow the steps in "IBM Network Utility Initiated Voluntary PPTP Tunnel" with the following exceptions:
| Note: | Prompts are slightly different in this step (See Table 20-64). |
Table 20-64. Specify L2TP in the Tunnel Profile
add tunnel-profile
Enter name: [ ]? L2TP peer
Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP]
Enter local host name: [ ] netU
Set shared secret? (Yes, No): [No] y
Shared secret for tunnel authentication: * will not appear
Enter again to verify:
Tunnel-Server endpoint address: [0.0.0.0] 192.168.141.34
Tunnel name: L2TP peer
Tunn Type 3: L2TP
Endpoint: 192.168.141.34
Local Hostname: netU
Tunnel 'NT' has been added
|
The L2TP sample scenario will establish the connection between a remote dial-up user in the branch and Network Utility in the corporate using L2TP tunneling. Refer to the sample network diagram in Figure 20-15.
Another application of VPN is to connect remote dial-in users to a central site over a public IP network, such as the Internet. The remote access server can be administrated by an ISP or by the user's company. This scenario demonstrates how to use the IBM Nways 2210/Network Utility as Remote LAN Access (RLAN) servers using the L2TP and Dial In Access to LANs (DIALs) features of the IBM Nways 2210/Network Utility.
Figure 20-15. L2TP Sample Configuration
 View figure. |
The IBM Nways 2210/Network Utility was used in this example, and the 2210 in the branch provides an RLAN access server for the remote dial-in users. An L2TP tunnel is set up between the branch router and the Network Utility in the data center so that the remote users can use the RLAN function in the Network Utility to access resources on the corporate intranet. Since the L2TP connection is IP-based, this traffic can also be sent through the IPSec tunnel if the IPSec is configured as well. With this alternative, L2TP is inside the IPSec tunnel.
The branch router 2210 was configured to allow a remote user to access the branch router via a V.34 dial-up modem and then extend the remote user's sessions to the corporate data center location over an IP network, such as the Internet, by using L2TP to tunnel the PPP session from the branch-office 2210 to the central-site IBM Network Utility.
Notes:
The first step in the RLAN configuration is to add a V.34 interface. This is shown in Table 20-65.
Table 20-65. Adding a V.34 Address and Configuring the V.34 Interface
Branch *t 6 Gateway user configuration Branch Config>add V34-ADDRESS Assign address name [1-23] chars []? local Assign network dial address [1-30 digits] []? 9193013461 Branch Config>set data v34 Interface Number [0]? 4 Branch Config>net 4 V.34 Data Link Configuration Branch V.34 System Net Config 4>set local-address Local network address name []? local |
You must map the V.34 port to the V.34 address. You can also set the modem initialization string and speed, but this example uses the default parameters. You can check the parameters you configured with the 'list all'command as shown in Table 20-66.
Table 20-66. Listing the Configuration of the V.34 Port
Branch V.34 System Net Config 4>LIST all
V.34 System Net Configuration:
Local Network Address Name = local
Local Network Address = 9193013461
Non-Responding addresses:
Retries = 1
Timeout = 0 seconds
Mode = Switched
Call timeouts:
Command Delay = 0 ms
Connect = 60 seconds
Disconnect = 2 seconds
Modem strings:
Initialization string =
Speed (bps) = 115200
|
The next step is to create the virtual interfaces used for dial-in connections. RLAN users use a special kind of dial circuit called a 'dial-in circuit'. In this scenario, one virtual interface is created for our single RLAN test user. However, you can create many more virtual interfaces. The practical limit is the number of async ports available on the router.
The dial-in interfaces are added from the talk 6 Config> prompt as shown in .
Table 20-67. Creating the Virtual Dial-in Interfaces
Branch Config>ADD DEVICE DIAL-IN Enter the number of PPP Dial-in Circuit interfaces [1]? Adding device as interface 6 Base net for this circuit [0]? 4 Enable as a Multilink PPP link? [no] Disabled as a Multilink PPP link. Defaulting Data-link protocol to PPP Add more dial circuit interface(s)?(Yes or [No]): Use "net " command to configure circuit parameters Branch Config>LIST DEVICES Ifc 0 Ethernet CSR 81600, CSR2 80C00, vector 94 Ifc 1 WAN PPP CSR 81620, CSR2 80D00, vector 93 Ifc 2 WAN PPP CSR 81640, CSR2 80E00, vector 92 Ifc 3 WAN PPP CSR 381620, CSR2 380D00, vector 125 Ifc 4 V.34 Base Net CSR 381640, CSR2 380E00, vector 124 Ifc 5 Token Ring CSR 6000000, vector 95 Ifc 6 PPP Dial-in Circuit Branch Config>NETWORK 6 Circuit configuration Branch Dial-in Circuit config: 6>LIST all Base net = 4 Circuit priority = 8 |
| Note: | Only PPP is supported over V.34. However, with DIALs, multiple protocols (IP, IPX, NetBIOS, 802.2, and LLC) can be supported over the PPP connection. |
In order to route IP through the V.34 interface, an IP address must be assigned to the interface. When the client dials in, the router automatically adds a static route to its routing table that says the next hop for the remote user is the IP address of the V.34 virtual interface.
The address must be on a different subnet from the destination LAN segment. You can use a real IP address or use an unnumbered IP. For the unnumbered IP, the format of the address is 0.0.0.n, where n is the interface number. Table 20-68 shows the dialog for this scenario. Interface 6 is the virtual interface for the test dial-in user.
Table 20-68. Configuring IP Addresses on the Virtual Interfaces
Branch IP config>LIST ADDRESSES IP addresses for each interface: intf 0 IP disabled on this interface intf 1 10.10.101.1 255.255.255.0 Local wire broadcast, fill 1 intf 2 IP disabled on this interface intf 3 IP disabled on this interface intf 4 IP disabled on this interface intf 5 10.10.1.1 255.255.255.0 Local wire broadcast, fill 1 intf 6 IP disabled on this interface Branch IP config>add address Which net is this address for [0]? 6 New address []? 0.0.0.6 Address mask [0.0.0.0]? 255.255.255.0 |
ARP-subnet routing must be enabled in order to allow the router to respond to ARPs when the next hop to the destination is over a different interface from the interface that is receiving the ARP request. This is the case with RLAN where the client IP address is on the same subnet as the router' s LAN interface, but the next hop (the V.34 interface) is on a different subnet. ARP-subnet routing is enabled as shown in Table 20-69.
Table 20-69. Enabling ARP-Subnet Routing
Branch IP config>ENABLE ARP-SUBNET-ROUTING Branch IP config>LIST ADDRESSES IP addresses for each interface: intf 0 IP disabled on this interface intf 1 10.10.101.1 255.255.255.0 Local wire broadcast, fill 1 intf 2 IP disabled on this interface intf 3 IP disabled on this interface intf 4 IP disabled on this interface intf 5 10.10.1.1 255.255.255.0 Local wire broadcast, fill 1 intf 6 0.0.0.6 255.255.255.0 Local wire broadcast, fill 1 |
This completes the configuration of the branch router for the basic DIALs function. The router is now restarted to activate the changes as shown in Table 20-70.
Table 20-70. Restarting the Router
Branch config> Branch *res Are you sure you want to restart the gateway? (Yes or [No]): yes |
For this example, the dial-in user' s PPP connection can be extended by setting up an L2TP tunnel between the 2210 in the branch location and Network Utility in the data center. The end user should be able to use the RLAN function in the Network Utility to connect to resources in the data center.
L2TP is a mechanism that involves a tunnel between an L2TP Access Concentrator (LAC) and an L2TP Network Server (LNS). In this scenario, the 2210 in the branch will be configured as the LAC and the Network Utility will be configured as the LNS. The first step is to enable L2TP in the LAC. See xTable 20-71.
Table 20-71. Enabling L2TP in the LAC (Branch Router)
Branch Config> FEATURE Layer-2-Tunneling Branch Layer-2-Tunneling Config>ENABLE L2TP Restart system for changes to take effect. Branch Layer-2-Tunneling Config>EXIT |
Next, a tunnel is created in the LAC. This is shown in Table 20-72.
Table 20-72. Creating L2TP Tunnel in the LAC (Branch Router)
Branch Config>ADD TUNNEL-PROFILE
Enter name: []? lns.org
Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP]
Enter local hostname: []? lac.org
set shared secret? (Yes, No): [No] y
Shared secret for tunnel authentication:
Enter again to verify:
Passwords do not match.
...try again
Shared secret for tunnel authentication:
Enter again to verify:
Tunnel-Server endpoint address: [0.0.0.0]? 10.10.101.2
Tunnel name: lns.org
TunnType: L2TP
Endpoint: 10.10.101.2
Local Hostname: lac.org
Tunnel 'lns.org' has been added
Branch Config>LIST TUNNEL-PROFILES
TunnType Endpoint Tunnel name Hostname
L2TP 10.10.101.2 lns.org lac.org
1 TUNNEL record displayed.
|
The following notes pertain to the LAC tunnel configuration:
In order to activate these changes, the router must be restarted.
The 2216 has been configured as an L2TP Network Server (LNS). First, L2TP was enabled in the LNS. This is shown in Table 20-73.
Table 20-73. Enabling L2TP in the LNS
Corp Config>FEATURE Layer-2-Tunneling Corp Layer-2-Tunneling Config>ENABLE L2TP Restart system for changes to take effect. Corp Layer-2-Tunneling Config>EXIT |
Then the tunnel is created in the LNS, pointing to the IP address and the name of the LAC. This is shown in Table 20-74.
Table 20-74. Creating L2TP Tunnel in the LNS (Corp Network Utility)
Corp Config>ADD TUNNEL-PROFILE
Enter name: []? lac.org
Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP]
Enter local hostname: []? lns.org
set shared secret? (Yes, No): [No] Y
Shared secret for tunnel authentication:
Enter again to verify:
Tunnel-Server endpoint address: [0.0.0.0]? 10.10.101.1
Tunnel name: lac.org
TunnType: L2TP
Endpoint: 10.10.101.1
Local Hostname: lns.org
Tunnel 'lac.org' has been added
Corp Config>LIST TUNNEL-PROFILES
TunnType Endpoint Tunnel name Hostname
L2TP 10.10.101.1 lac.org lns.org
1 TUNNEL record displayed.
|
| Note: | If you are using shared secrets, the key must match the one configured in the LAC. |
You can modify the PPP parameters for the L2TP tunnel. However, these parameters will be negotiated between the LAC and the LNS. The LAC acts as a proxy for the client PC in the PPP negotiation. An authentication protocol must be enabled for the L2TP tunnel. The default PPP parameters on the LNS were used for this scenario.
Next, the virtual interfaces over which the PPP connections will be terminated were added. These are analogous to the dial-in interface that was added in the branch router when it was configured for the DIALs function. However, in this case, the users are coming in through an L2TP tunnel instead of a V.34 interface.
In the LNS, the virtual interfaces are added from the L2TP feature configuration prompt. (In the LAC, they were added from the talk 6 main prompt.) This is shown in Table 20-75.
Table 20-75. Adding the Virtual Interface
Corp Config>FEATURE Layer-2-Tunneling Corp Layer-2-Tunneling Config>ADD L2-NETS Additional L2 nets: [0]? 2 Add unnumbered IP addresses for each L2 net? [Yes]: Adding device as interface 6 Defaulting Data-link protocol to PPP Adding device as interface 7 Defaulting Data-link protocol to PPP Enable IPX on L2T interfaces?(Yes or [No]): Enable transparent bridging on L2T interfaces?(Yes or [No]): Bridge configuration was not changed. Restart router for changes to take affect. Corp Layer-2-Tunneling Config>EXIT |
In order to route IP through the L2 nets, an IP address must be assigned to the interface. When the client establishes the PPP connection through the L2TP tunnel, the router automatically adds a static route to its routing table that says that the next hop for the remote user is the IP address of the L2TP virtual interface. The address must be on a different subnet from the destination LAN segment.
The IP addresses for these interfaces are added when you create the interfaces. By default, they are unnumbered IP addresses. The format of the address is 0.0.0.n where n is the interface number (for example, for interface 7, the unnumbered IP address would be 0.0.0.7).
| Note: | If you need to change the default IP address associated with an L2TP net, you can do so via the IP config prompt in talk 6. However, unnumbered IP addressing works very well for RLAN because users connect to an L2TP net arbitrarily and the particular IP address associated with an L2TP net is not very critical. |
ARP-subnet routing must be enabled in order to allow the router to respond to ARPs when the next hop to the destination is over a different interface from the interface that is receiving the ARP request. This is the case with RLAN where the client IP address is on the same subnet as the router' s LAN interface but the next hop (the L2TP virtual interface) is on a different subnet. ARP-subnet routing is enabled as shown in Table 20-76.
Table 20-76. Enabling ARP-Subnet Routing
Corp config>protocol ip Corp IP config>ENABLE ARP-SUBNET-ROUTING Corp IP config>EXIT |
Next, the method for clients to obtain an IP address is defined. The DIALs server in the Network Utility needs to be configured as if the users were dialing in via ISDN or V.34 rather than tunneling in through an L2TP tunnel. DIALs users need to be assigned an IP address that is on the same subnet as the LAN interface to which they wish to connect. There are five methods available:
The methods for the clients to obtain an IP address are configured from the global DIALs menu. The client, user ID, interface and IP Pool methods are enabled. The router will attempt to use the first method that is enabled (in the order listed). You can also define primary and secondary domain name servers whose addresses are passed to the client during the IPCP negotiations. This is shown in Table 20-77.
Table 20-77. Listing Methods to Obtain IP Adresses
Corp Config>FEATURE DIALs Dial-in Access to LANs global configuration Corp Config>FEATURE DIALs Dial-in Access to LANs global configuration Corp DIALs config>LIST IP-ADDRESS-ASSIGNMENT DIALs client IP address assignment: Client : Enabled UserID : Enabled Interface : Enabled Pool : Enabled DHCP Proxy : Disabled |
In this scenario, the IP address for DIALs users from an IP pool is allocated. This is shown in Table 20-78.
Table 20-78. Adding IP Pool for DIALs Users
Corp Config>FEATURE DIALs
Dial-in Access to LANs global configuration
Corp DIALs config>ADD IP-POOL
Base address []? 10.10.10.11
Number of addresses [1]? 20
Corp DIALs config>LIST IP-POOLS
Configured IP address pools:
Base Address Last Address Number
------------ ------------ ------
10.10.10.11 10.10.10.30 20
|
At this point, the tunnel is configured in both the LNS and LAC, and the DIALs feature is configured in the LNS. Now, the PPP users that will tunnel to the LNS need to be configured. There are two ways to configure the PPP users to be tunneled:
Table 20-79 shows the definition of a Rhelm-based user on the Network Utility in the data center.
Table 20-79. Adding a Rhelm-Based L2TP User
Corp Config>ADD PPP-USER
Enter name: []? sharif@lns.org
Password:
Enter again to verify:
Allow inbound access for user? (Yes, No): [Yes]
Will user be tunneled? (Yes, No): [No]
Is this a 'DIALs' user? (Yes, No): [Yes]
Type of route? (hostroute, netroute): [hostroute]
Number of days before account expires [0-1000] [0]?
Number of grace logins allowed after an expiration [0-100] [0]?
IP address: [0.0.0.0]?
Enter hostname: []?
Allow virtual connections? (Yes, No): [No]
Give user default time allotted ? (Yes, No): [Yes]
Enable callback for user? (Yes, No): [No]
Will user be able to dial-out ? (Yes, No): [No]
Set ECP encryption key for this user? (Yes, No): [No]
Disable user ? (Yes, No): [No]
PPP user name: sharif@lns.org
User IP address: Interface Default
Netroute Mask: 255.255.255.255
Hostname: Virtual Conn: disabled
Time alotted: Box Default
Callback type: disabled
Dial-out: disabled
Encryption: disabled
Status: enabled
Login Attempts: 0
Login Failures: 0
Lockout Attempts: 0
Account Expiry: Password Expiry:
Is information correct? (Yes, No, Quit): [Yes]
User 'sharif@lns.org' has been added
|
For user-based tunneling, the ID is defined in both the LAC and LNS. Table 20-80 shows the definition of a user-based ID on the 2210 in the branch office. This user is set to be tunneled, and the router is notified to set up the L2TP tunnel when the user dials in. The destination IP address of the other tunnel endpoint is specified along with the hostname of the 2210 to use when creating the tunnel.
Table 20-80. Adding a User-Based Tunneling User in the 2210 (LAC)
Branch Config>ADD PPP-USER
Enter name: []? shoma
Password:
Enter again to verify:
Allow inbound access for user? (Yes, No): [Yes]
Will user be tunneled? (Yes, No): [No] y
Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP]
Enter local hostname: []? lac.org
Tunnel-Server endpoint address: [0.0.0.0]? 10.10.101.2
PPP user name: shoma
TunnType: L2TP
Endpoint: 10.10.101.2
Local Hostname: lac.org
Is information correct? (Yes, No, Quit): [Yes] y
User 'shoma' has been added
|
| Note: | As soon as you specify that the user will be tunneled, the router knows to not ask you whether you want the DIALs function enabled for this user, what the IP address of the client should be, or any of the other parameters that you are prompted for when defining a DIALs user. This is because the DIALs function for this user is being provided by the Network Utility. The 2210 is merely providing a gateway service to the Network Utility. |
Table 20-81 shows the definition of the same user-based ID on the 2216 in the data center. A normal DIALs user is defined here. This user is not a tunneled user since he is authenticated by the DIALs function by the time he is authenticated, the L2TP headers have all been stripped off and the packets are just normal PPP packets. This completes the configuration of the LNS.
Table 20-81. Adding a User-Based Tunneling User in the Network Utility (LNS)
Corp Config>ADD PPP-USER
Enter name: []? shoma
Password:
Enter again to verify:
Allow inbound access for user? (Yes, No): [Yes]
Will user be tunneled? (Yes, No): [No]
Is this a 'DIALs' user? (Yes, No): [Yes]
Type of route? (hostroute, netroute): [hostroute]
Number of days before account expires [0-1000] [0]?
Number of grace logins allowed after an expiration [0-100] [0]?
IP address: [0.0.0.0]?
Enter hostname: []?
Allow virtual connections? (Yes, No): [No]
Give user default time allotted ? (Yes, No): [Yes]
Enable callback for user? (Yes, No): [No]
Will user be able to dial-out ? (Yes, No): [No]
Set ECP encryption key for this user? (Yes, No): [No]
Disable user ? (Yes, No): [No]
PPP user name: shoma
User IP address: Interface Default
Netroute Mask: 255.255.255.255
Hostname: Virtual Conn: disabled
Time alotted: Box Default
Callback type: disabled
Dial-out: disabled
Encryption: disabled
Status: enabled
Login Attempts: 0
Login Failures: 0
Lockout Attempts: 0
Account Expiry: Password Expiry:
Is information correct? (Yes, No, Quit): [Yes] y
User 'shoma' has been added
|
The Network Utility must be restarted in order to activate these changes.
Now that the configuration is in place, the L2TP and RLAN configurations can be tested. The L2TP can be tested by dialing in from the remote PC, first with the Rhelm-based user ID and then with the User-based ID.
IP connectivity can be tested using PING from the PC client to the Network Utility. L2TP can be monitored from ELS using disp sub l2 all. A sample talk 2 session from the Network Utility LNS is shown in Table 20-82.
Table 20-82. Monitoring L2TP from ELS
Corp *TALK 2 00:04:27 L2.052: Tunnel 7042/0 has 15 seconds to establish itself 00:04:27 L2.050: EVENT Rx-SCCRQ,tid=7042/0,state=Idle 00:04:27 L2.048: RCV l2tpGetHostname, tid=7042/0 00:04:27 L2.058: Peer TunnelID = 48802 00:04:27 L2.060: Peer Hostname = lac.org 00:04:27 L2.047: Tunnel 7042/48802 State Changed Idle -> Authorizing 00:04:27 L2.074: Upcall from AAA subsystem, request SUCCESS 00:04:27 L2.050: EVENT Continue-SCCRQ,tid=7042/48802,state=Authorizing 00:04:27 L2.048: RCV SCCRQ, tid=7042/48802 00:04:27 L2.058: Peer TunnelID = 48802 00:04:27 L2.060: Peer Hostname = lac.org 00:04:27 L2.058: Peer Rcv Window = 4 00:04:27 L2.058: Peer Challenge = 0 00:04:27 L2.049: SEND SCCRP, tid=7042/48802 00:04:27 L2.035: Tunnel Auth Create Challenge, Tid=7042/48802, Len=16 00:04:27 L2.035: Tunnel Auth Create Challenge Response, Tid=7042/48802, Len=16 00:04:27 L2.044: Allocating UDP port 1026 for tunnelid=7042 00:04:27 L2.041: SND L2TP:F=C802,L=121,Tid=48802,Cid=0,NS=0,NR=1,O=0 00:04:27 L2.047: Tunnel 7042/48802 State Changed Authorizing -> Wait-ctl-cnn 00:04:27 L2.040: RCV L2TP:F=C800,L=42,Tid=7042,Cid=0,NS=1,NR=1,O=0 00:04:27 L2.050: EVENT Rx-SCCCN,tid=7042/48802,state=Wait-ctl-cnn 00:04:27 L2.048: RCV SCCCN, tid=7042/48802 00:04:27 L2.057: Processing Challenge Response from Peer 4.7.3.3 00:04:27 L2.039: NOTE:SCCCN: Tunnel Authenticated 00:04:27 L2.047: Tunnel 7042/48802 State Changed Wait-ctl-cnn -> Established 00:04:27 L2.040: RCV L2TP:F=C800,L=48,Tid=7042,Cid=0,NS=2,NR=1,O=0 00:04:27 L2.007: LNS Allocated L2 net 8 00:04:27 L2.020: RCV Inbound-Call-Request, callid=25642, net=8 00:04:27 L2.021: SEND Inbound-Call-Reply, callid=25642, net=8 00:04:27 L2.041: SND L2TP:F=C802,L=44,Tid=48802,Cid=1156,NS=1,NR=3,O=0 00:04:27 L2.013: L2TP Call 25642 State Changed Idle -> Wait Connect 00:04:27 L2.030: LNS Forcing LCP option ACFC 00:04:27 L2.039: NOTE:Proxy-LCP Callback received 00:04:27 L2.009: Call Rcv Proxy-Auth-Type AVP,attr=29,val=4,len=8,flag=8008 00:04:27 L2.009: Call Rcv SEQUENCING_REQUIRED AVP,attr=39,val=0,len=6,flag=800 00:04:27 L2.013: L2TP Call 25642 State Changed Wait Connect -> Established 00:04:27 L2.015: Call Established-LNS,net=8,speed=115200,flags=4802 00:04:27 L2.017: Using Proxy-LCP AUTH on net 8 00:04:27 L2.021: SEND Set-Link-Info, callid=25642, net=8 00:04:27 L2.041: SND L2TP:F=C802,L=36,Tid=48802,Cid=1156,NS=2,NR=4,O=0 00:04:27 L2.040: RCV L2TP:F=C800,L=12,Tid=7042,Cid=0,NS=4,NR=3,O=0 00:04:32 L2.022: L2TP PAYLOAD RCVD 53 bytes, net 8, callid=25642 00:04:32 L2.024: L2TP PAYLOAD SEND 6 bytes, net=8, callid=25642 00:04:32 L2.041: SND L2TP:F=6902,L=18,Tid=48802,Cid=1156,NS=1,NR=2,O=0 00:04:32 L2.024: L2TP PAYLOAD SEND 8 bytes, net=8, callid=25642 |
The L2TP tunnel state can be checked from talk 5 as shown in Table 20-83.
Table 20-83. Monitoring L2TP from Talk 5
Branch *TALK 5
Branch +FEATURE Layer-2-Tunneling
Layer-2-Tunneling Information
Branch Layer-2-Tunneling Console> TUNNEL STATE
Tunnel ID | Type | Peer ID | State | Time Since Chg | # Calls | Flags
35589 | L2TP | 58774 | Established | 0: 1:24 | 1 | TL
F
Branch Layer-2-Tunneling Console> TUNNEL STATISTICS
Tunnel ID | Type | Tx Pkts | Tx Bytes | Rx Pkts | Rx Bytes | RTT | ATO
35589 | L2TP | 108 | 7883 | 104 | 5388 | 5 | 5
Corp *TALK 5
Corp +FEATURE Layer-2-Tunneling
Layer-2-Tunneling Information
Corp Layer-2-Tunneling Console> TUNNEL STATE
Tunnel ID | Type | Peer ID | State | Time Since Chg | # Calls | Flags
58774 | L2TP | 35589 | Established | 0: 2: 9 | 1 | TL
F
Corp Layer-2-Tunneling Console> TUNNEL STATISTICS
Tunnel ID | Type | Tx Pkts | Tx Bytes | Rx Pkts | Rx Bytes | RTT | ATO
58774 | L2TP | 108 | 5540 | 112 | 8035 | 5 | 5
|
This completes the configuration and monitoring of L2TP for Remote LAN Access using IBM 2210 and Network Utility.